This invention relates generally to the fields of computer systems and access authorization. More particularly, a system and method are provided for implementing a distributed capability-based authorization architecture.
Organizations and enterprises implement some form of access control or authorization in their computing environments in order to protect their resources from damage and/or unauthorized use. An authorization scheme is usually intended to ensure that only authorized users are granted access to the organization's computing resources.
Traditional authorization schemes employ an ACL (Access Control List) model, in which an ACL is associated with each resource (e.g., file, directory, disk, communication device, programming object) to which access is to be restricted. An ACL is designed to identify, for a specific resource, those users that are permitted access to the resource.
One disadvantage of the ACL model is the difficulty of managing ACLs for many resources. Typically, one ACL is needed for each resource to which access is to be screened. Therefore, this model does not scale well, because every time such a resource is created or added to the computing environment, another ACL must be generated. In addition, maintaining ACLs can be time-consuming, because they may need to be updated every time a new user is added, an existing user departs, a user's permission to use a resource is changed, a user's identity changes, etc.
In contrast, in a capability-based authorization scheme, access authorization information would be associated with subjects (e.g., users, roles) rather than objects (e.g., resources) to which the subjects desire access. Thus, a capability-based authorization scheme could avoid some or all of the difficulties associated managing ACLs.
Previous attempts to provide capability-based authorization schemes have been unsatisfactory, in part because they have limited scope. More specifically, attempted schemes are limited to implementation within one address space, associated with one JVM (Java Virtual Machine) for example. Thus, in a Java environment, within each address space, a separate authorization scheme would have to be implemented and maintained. There would be little, if any, ability to share authorization information across address spaces and each scheme would have to be updated separately.
Also, many authorization schemes only allow access privileges to be granted to users. This typically requires every user's authorization profile to be individually configured—every user is granted his or her necessary authorizations. Even if multiple users have the same access requirements, they would each have to be configured separately.
Thus, beyond the difficulties of managing authorization privileges or permissions as the number of objects and/or subjects increase, it can be difficult to manage how those privileges or permissions are granted. In particular, it can take a significant portion of a security administrator's time to grant, revoke and alter the access privileges of subjects (e.g., users) within an organization's computing environment, as subjects come and go and as the configuration of the environment changes (e.g., as resources are added or removed). This is because typical security policies (e.g., the default policy for the Java programming language) do not include administrative functionality for managing access privileges. As a result, it is not possible to control, with fine granularity, which subjects can make changes to the security policy, and what kind of changes they can make.